home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ShareWare OnLine 2
/
ShareWare OnLine Volume 2 (CMS Software)(1993).iso
/
elecmail
/
rdmap116.zip
/
ROADMAP.DOC
< prev
next >
Wrap
Text File
|
1992-10-27
|
23KB
|
480 lines
***************************** Roadmap V1.10 *****************************
*************************************************************************
Purpose: Roadmap will automatically create Squish/Qmail/FD
compliant ROUTE.CFG files for your entire NETWORK.
NOTE: Roadmap is a very complicated program, and requires
that anyone in your NET using the program coordinate
information with one another. Failure to do so will
result in ROADMAP creating incorrect route.cfg files
that, at best, may not create complete ROUTE.CFG
files for every node. At worst, ROADMAP will create
ROUTE.CFG files that "ping-pong" mail between systems.
*************************************************************************
************************ Files Used and created *************************
Roadmap requires 3 input files that it gets information from.
They are:
Nodelist Roadmap reads any St. Loius style nodelist directly.
All you do is tell roadmap where your "nodelist"
directory is, and roadmap will automatically select
the latest nodelist to use.
Roadmap.cfg Roadmap has a configuration file. In this file is
all the "custom" information for your particular
system. These include your nodelist path,
zone:net/node #, who will accept your LPM mail,
and a "template" ROUTE.CFG file that roadmap "modifies"
every time it runs.
Roadmap.exc Roadmap.exc is the file that has details on your
net's phone exchange information.
Using this information, roadmap creates 2 output files;
ROADMAP.TMP This is the "solved" NET routing file... This is
the file the "insert_map" verb writes in your
route.cfg file. I left it here just in case you
have another use for this file. If not, it
simply could be deleted in a batch file every
time the program is run.
ROUTE.CFG This is the actual output file of ROADMAP. This
file is the actual ROUTE.CFG file that can be used
by your mailer. For FD users, you will have to rename
this to ROUTE.FD before you can use it. Again, a
perfect job for a batch file (Or .CMD file for us
OS/2 users)
************************************************************************
************************** Operation Overview **************************
Roadmap first opens it's configuration file. From here, it finds out
where it can find a nodelist, it's zone:net/node#, node numbers
that it shouldn't "solve" for (exclude from the output), the areacode
it is in (as seen in the nodelist).
Roadmap then reads "operating" variables into it. It finds out who it
can send LPM to, and what phone exchanges within your net have at least
one node participating in LPM distribution.
From there, it reads how you want to treat your "output". I.E. what
verbs you want to use for the SEND's and ROUTE's it creates.
Lastly, the end of the configuration file holds the "template" of your
configuration file. This template holds all the "outside" net routing,
since roadmap will only solve your own net's routing. This also holds
any "specially treated" nodes within your net. For Example, lets say a
node within your net polls you for echomail. If you allow roadmap to
"route" this node, your tosser will route echomail along that route.
Usually, routed echomail is looked down upon in fidonet, and it is
not advised without prior consent of all involved. Routed echomail
is something much different than routed netmail. Routed Netmail
is usually low in volume, routed echomail can be megabytes a day!.
Also, if you have any tosser schedules, you MUST include them in your
template. Again, ALL ROADMAP DOES is CREATE a ROUTING FILE FOR YOUR NET!!
Anything else has to still be done manually!!, and those manual entries
must be put in your TEMPLATE.
After ROADMAP has read it's configuration file, it then reads the
phone exchanges file. Here it groups the exchanges into calling groups,
and finds out what other calling groups the group can call..
For Example:
Group Wallingford
Exchanges 265,269,284,294,949
Calling Meriden,Cheshire,New_Haven
End Wallingford
The above is an entry in a typical ROADMAP.EXC file for Wallingford, CT.
Roadmap reads this information, and from it does the following:
It creates a calling group called WALLINGFORD.
It then is told information about group Wallingford. This information
is in the form of what phone exchanges make up the group, and what
other groups WALLINGFORD can call.
In this case, it knows that if the prefix of a phone # in your areacode
begins with 265,269,284,294, or 949, it belongs to group WALLINGFORD,
and that phone exchange can then call itself, and also the
calling groups MERIDEN, CHESHIRE and NEW_HAVEN..
Next, roadmap looks in your NODELIST directory, finds the latest NODELIST
by date (this way it doesn't get confused in the beginning of JANUARY),
and then opens the nodelist.
Roadmap scans the nodleist until it finds your Zone:net. It then, one by
one, reads in every node in your net. It stores the node number, and then
looks at the phone prefix for the phone number of the node. If there is
no phone number (in the case of PVT nodes), it reports that the node
is not within your areacode, or is PVT! and continues with the next node,
disregaurding the "offending" node..
If it does find a phone number, it "checks" the prefix, and finds which
calling group it belongs to. ROADMAP does NOT use the "location" found
in the nodelist, it uses the phone number to find the "group" it is
in as you specified in ROADMAP.EXC. If it cannot locate a dialing prefix
match from the ROADMAP.EXC file, it warns you, and then throws that node
away. After all the nodes in the net are processed, it closes the
nodelist, and proceeds to "solve" the routing of your NET.
From here, roadmap looks, node by node, on how to create a NO-COST
link to that node from your node. It goes by groups. Roadmap's logic
can be confusing at first, and unfortunatly explaining things is NOT
one of my strong points, but here goes:
Roadmap, while reading in the nodelist, searched for you. Let's say
you are 1:141/865 (me). It finds out that your dialing prefix is
949, which is part of group WALLINGFORD, thus you are in group WALLINGFORD.
It now takes a node, and attemps to find a free link between you and the
node in question.
If you are local to the node, the node is placed at the beginning of
the "solved" route file, with a SEND ???? in front of it. The ???? is
replaced with the verb you specified in the SEND_VERB keyword of the
configuration file.
If the node is NOT local to you, it will attempt to find the shortest
free route to that node. If it finds a route, it will place the node
in the output "solved" file, with a SEND ???? Z:N/ROUTER in front
of it, and any other nodes to be routed the same way. The ???? is
replaced with the verb you specified in the ROUTE_VERB keyword in
the configuration file. The ROUTER will be replaced with the node
number of the router it chose as the best person to send this node's
mail to.
If ROADMAP is unable to find a toll-free link, it will
place the node at the end of the "solved" route file, and will place
a SEND ???? in front of it, and any other nodes that cannot be routed
free. The ???? is replaced with the verb you specified in the
NOTLOCAL_VERB keyword in the configuration file.
PLEASE NOTE: A TOLL FREE LINK means that NO NODE using roadmap
will incur any expense in delivering the mail within the NET.
ROADMAP IS DESIGNED NEVER TO MAKE ANY NODE MAKE
AN LD CALL TO DELIVER NETMAIL WITHIN THE NET. IF
ROADMAP CANNOT FIND A FREE LINK, IT DEAD-ENDS THAT
NODE ON YOUR SYSTEM. You can either choose to send
the mail yourself, incurring the charges yourself,
or putting that node's mail on HOLD.. For this
reason, it is suggested the the ROUTE_TO nodes
you choose also be using ROADMAP. This way, No-one
will force any other node to make LD call's on it's
behalf.
When roadmap cannot find a link in only a few steps (I.E. it's not local
to you, or your routers), roadmap creates a "tree", starting with your
routers, and builds search branches of that tree, one branch for every
group that can be called (local to) by a group above it.. Example:
Wallingford (Base of Tree, Level 1)
|------------------|-------------------|
|--------------Meriden |-----Cheshire |------New_Haven (Level 2)
Southington Waterbury Branford Milford Guilford (Level 3)
etc..etc..etc..
Roadmap keeps growing the search tree until it finds the group it's looking
for (The group the node we are looking for is found). Once it finds this
group, roadmap "looks up" to find which branch (level 2) spawned it. Level
2 is really all your routers, and by "looking up", it knows which router
to route this node to.
PLEASE NOTE: In this scenario, roadmap uses the CAN_ROUTE groups
to determine if a group can be used in the search tree.
For example, if, when ROADMAP starts searching group
MERIDEN sees that MERIDEN can call group SOUTHINGTON,
it marks SOUTHINGTON as a possible search "branch" on
it's next pass (Next lower level). When roadmap gets
to that level (Level 4 will expand Southington's calling
area in the example above), roadmap first checks to see
if a node exists in Southington that can accept routed
mail. It gets this from the CAN_ROUTE entries in the
roadmap.cfg file. If group SOUTHINGTON does not appear,
roadmap ignores Southington, saying that even if I
can get to my target group via Southington, it won't
matter because no-one in Southington can accept my mail.
Now, let's examine this case:
Wallingford
|
Cheshire
|
Waterbury
|
Woodbury
|
Newtown
|
Danbury
This is the shortest distance from Wallingford to Danbury. If all those
towns above are in my CAN_ROUTE list, that's the route ROADMAP will choose
when it trys to find a route to Danbury. If, however, I take a town out
of the list, ROADMAP will attempt to find another route to DANBURY.
For example, lets say I take Cheshire out:
Wallingford
|
Meriden
|
Southington
|
Waterbury
|
Woodbury
|
Newtown
|
Danbury
This is what happens, assuming all the above towns ARE in my
CAN_ROUTE list. It said I cannot use Cheshire, but found out
that Meriden can call Southington, which can call Waterbury, and
chose that route. If it could not find a new route, it would mark
that node as un-routable, and place it in the SEND LD line.
Now, for the reason why ROADMAP's CAN_ROUTE list HAS to be coordinated
within a NET...
Lets, for sake of argument, say the following towns are interconnected
like this:
Wallingford----------------------
| |
Cheshire New Haven
| |
Waterbury Milford
| |
Woodbury-------------| Bridgeport
| Seymour |
Newtown |-----------
|
Danbury
As you can see, both Bridgeport and Woodbury can call Seymour.
Now, lets say that ROADMAP attempts to solve the Cheshire
nodes path to Danbury. WATERBURY, WOODBURY, and NEWTOWN are
all in the node's CAN_ROUTE list, so ROADMAP determines the
shortest distance to Danbury is .via. those 3 hops.
Now, ROADMAP on the system in Milford attempts to SOLVE for
Danbury. It has BRIDGEPORT, SEYMOUR, WOODBURY, and NEWTOWN
in it's list, and so, ROADMAP realizes that the shortest way
to Danbury is going through Seymour. A total of 4 hops.
Now, the guy in BRIDGEPORT doesn't have SEYMOUR in his CAN_ROUTE list,
so when ROADMAP solves for Danbury on his system, it says,
hey, Seymour would be the shortest, but I can't go that way, so
I have to go all the way around. MILFORD, NEW_HAVEN,WALLINGFORD,
CHESHIRE,WATERBURY,WOODBURY and NEWTOWN are in his CAN_ROUTE list,
and so roadmap determines the "best available" way to route to
Danbury is through Milford...
We have a "ping-Pong" problem here... Milford will attempt to
route Netmail destined to Danbury through Bridgeport. Bridgeport,
on the other hand, will route it through Milford... So, the nodes
will end up sending this poor little innocent netmail message back
and forth between the node in Milford and the node in Bridgeport...
This is why IT IS VERY IMPORTANT that EVERYONE's CAN_ROUTE lists
be the same in a NET!!!!!!!
***********************************************************************
******************** ROADMAP.CFG file Keywords ************************
***********************************************************************
Here is the list of keywords that can be included in the .CFG file, and
their explanation. All keywords must be seperated from their arguments
by at least one space, although any number of spaces can be used for
viewability. Keywords ARE NOT CASE SENSITIVE.
NODELIST Place the Path to where you store your NODELIST directoy.
MY_ZONE Your fidonet Zone number.
NY_NET Your Fidonet NET number.
NY_NODE Your Fidonet NODE number.
EXCLUDE List the nodes that you DO NOT want in the output.
These are usually numbers if you have alias numbers,
such as an administrative number. But, any number can
be excluded.
You can have a Maximum of 20 numbers here, and you can
have them spread out over more than one EXCLUDE keyword.
AREACODE Your Areacode, as seen in the nodelist.
ROUTE_TO The nodes that have agreed to accept your routed mail.
It is suggested that these nodes also run ROADMAP.
You can have a Maximum of 10 Nodes that you can send
your ROUTED mail to, and they can be spread out over
more than one ROUTE_TO keyword.
CAN_ROUTE This is a list of the calling groups that have a node
in them that is willing to route mail.
A Maximum of 50 CAN_ROUTE Groups can be given, and
you can spread them out over more than one CAN_ROUTE
keyword, as shown in the sample .CFG file.
SEND_VERB This is the "modifier" that ROADMAP will place after
any node that you can call locally, in the ROUTE.CFG
file. This is the verb (Crash, Normal, Direct, Hold)
that your mailer will use when determining the priority
of the mail to these nodes.
ROUTE_VERB This is the "modifier" ROADMAP will place after the
ROUTE verb in the ROUTE.CFG file. This is the verb
(Crash, Normal, Direct, Hold) that your mailer will
use when determining the priority to send this mail
to the node (Your Routers, the nodes in you ROUTE_TO
list).
NOTLOCAL_VERB This it the "modifier" that roadmap will pace in your
ROUTE.CFG file after and nodes that cannot be reached
via a toll free link. Placing HOLD here will cause
your mailer NEVER to call these nodes, thus NOT making
any LD calls within your net. You could choose to
place any other "modifier" here, so as to deliever
the mail yourself, if your system gets any mail for
these nodes.
NOTLOCAL_ROUTE This keyword is optional. If this keyword is not used,
ROADMAP will create a "SEND (NOTLOCAL_VERB) nodes....
for all nodes that cannot be routed within the net
toll free.
If this keyword is used, ROADMAP will route all the
nodes that cannot be routed for free to this node.
THIS CAN BE DANGEROUS, AS IT ALLOWS ROADMAP TO SEND
MAIL TO ANOTHER SYSTEM THAT MAY ULTIMATLY MAKE THAT
SYSTEM CALL LONG DISTANCE!!! USE THIS KEYWORD WITH
CAUTION, AND CHECK WITH THE NODE YOU PLAN TO ROUTE
THESE 'UNROUTABLE' NODES TO BEFORE YOU DO THIS.
BEGIN_CFG This marks the Beginning of you ROUTE.CFG template.
Roadmap needs a TEMPLATE ROUTE.CFG file, that it will
place it's "answers" into. This is because ROADMAP
cannot solve out of net LPM, and other special
routing that you and others may have already established.
The best thing to do is take the sample ROADMAP.CFG file
that came with the package, and delete EVERYTHING after
BEGIN_CFG. Then, append a copy of your PRESENT ROUTE.CFG
to the ROADMAP.CFG file, after the BEGIN.CFG keyword.
INSERT_MAP This is used inside the ROUTE.CFG TEMPLATE. Wherever
you place this verb, ROADMAP will replace this verb
with the routing it determined for your NET. This
verb can be used as many times as you want within the
template. (Just in case you have more than one event that
requires NET routing).
END_CFG This signifies the End of your ROUTE.CFG template file,
and usually the end of your ROADMAP.CFG file as well.
**********************************************************************
********************** ROADMAP.EXC File Format ***********************
**********************************************************************
The ROADMAP.EXC file holds all the phonde dialing info for your
particular area. This information may not be easy to find; it took
me almost a week of searching various phone books (The front usually
has a map of the calling area it covers with dialing exchanges
and calling coverages).
First, you must pick a group name for every DIFFERENT calling group
in your area. The group name you pick is arbitrary, so long as it
has no spaces in it, and is not longer than 20 characters. I attempted
to represent the towns (logical, huh?) that they encompass. Usually,
the phone company has already named these groups. For Example, in the
front cover of the NEW_HAVEN, CT phone book, the phone company has
a little map showing all the dialing prefixes in NEW_HAVEN, and then
little arrows to surrounding towns that NEW_HAVEN can dial. That's what
you want. Physically, NEW_HAVEN, CT includes other towns, like North
Haven, and Hamden. But, ALL their phonde numbers have the same dialing
"range", so you include them in one group!
You organize a group like this in the ROADMAP.EXC file:
Group NEW_HAVEN
Exchanges xxx,yyy,zzz,aaa,bbb
Exchanges xxy,yyx,zza,aab,bbz
Calling WALLINGFORD,MILFORD
Calling CHESHIRE,BRANFORD
End NEW_HAVEN
Please note that you can have any number of EXCHANGES and CALLING keywords
within a group. You can have 75 Exchanges (dialing Prefixes) and 20 Calling
groups.
You can have a Maximum of 75 Groups.
When creating the calling groups, if you say that a group can call another
group, you MUST define that other group somewhere in your ROADMAP.EXC file.
For example, I mentioned WALLINGFORD, MILFORD, CHESHIRE and BRANFDORD
above. This means that I MUST define those groups in my ROADMAP.CFG also.
Also, when I do define those groups, I put NEW_HAVEN in as a group it
can call.
Hint: Net 141's boundry is Southington. Southington can
call BRISTOL, but BRISTOL is not part of NET 141. It is
our neighboring net, NET 142. Which means when I solve for
net 141, I will NEVER have a BRISTOL node to deal with.
So, even though SOUTHINGTON can dial BRISTOL, I didn't
put BRISTOL in SOUTINGTON's calling info. This way,
I don't have to define BRISTOL in ROADMAP.EXC.
It's pretty self explanatory, take a peek at the sample ROADMAP.EXC file
if you still have any questions. If you still have any questions,
comments, suggestions, or that "b" word (Bug reports), feel free
to Netmail me at 1:141/865, or log into the BBS at (203) 949-0375.
While I'm here, I'd like to thank some people that helped me with
beta-testing this program, putting up with my numerous phone calls,
and netmail messages attempting to check ROADMAP, and all of NET 141
in general for being so receptive and helpful.
Brian Bonfietti (141/1130) , Dave Drouin (141/805) , Bob Morris (141/333)
Furlan Primus (141/1100) , Tom Ruddy (141/755) , Don Dawson (141/730)
Joel Lambert (141/455) , Terry Wodek (141/375) , Jim Ryan (141/9)
Mark Terrace (141/340) , Phil Palumbo (141/336) , Don Bates (141/814)
Steve Sekula (141/110) , Chris Regan (141/565) , Brian Dodds (141/1170)
And last but not least, Registration:
I wrote this to help out Fidonet, I don't want money for it. Maybe
a note letting me know you use it would be nice, but not nessesary.
I do ask you to do one little thing though. If you use it, go out,
and buy a kid an ice cream cone. Spend some time with a kid. You'll
both enjoy the time you spend together!
Andre Normandin
NETWORK SOLUTIONS
Fidonet: 1:141/865
BBS: (203) 949-0375
